1. Technical Field
The present invention relates generally to an improved data processing system and, in particular, to a method and system for presenting glyphs. Still more particularly, the present invention provides a method and system for varying the quality or performance of glyph presentation processing on a glyph-by-glyph basis within a data processing system.
2. Description of Related Art
Almost all computer programs, which have a graphical user interface or which display text to a user, employ some type of character display subsystem. In recent years, these display methods have become more sophisticated, and new terminology has arisen to satisfy the need for more precise concepts. Many applications currently refer to glyphs, characters, and fonts.
It is important that one understand the separate concepts behind the words xe2x80x9ccharacterxe2x80x9d, xe2x80x9cglyphxe2x80x9d, and xe2x80x9cfontxe2x80x9d. A xe2x80x9ccharacterxe2x80x9d is a symbol that represents items like letters and numbers in a given writing system, for example, lowercase-g. When a given character is drawn on a presentation medium, a shape is presented which represents the character. This shape is called a xe2x80x9cglyphxe2x80x9d. A font is a collection of glyphs.
Characters and glyphs do not have a one-to-one correspondence. As an example, lowercase-a-acute can be represented by two glyphs: lowercase-a and acute. Another example is ligatures, such as ligature-fi, which is a single glyph usually representing two characters: f and i. This lack of a one-to-one correspondence becomes an even larger problem when one moves from a Latin font to a non-Latin or Asian font.
A font is a collection of glyphs and may have many typefaces, e.g., heavy, medium, oblique, gothic, and regular. All of these typefaces have similar typographic features and can be recognized as members of the same family. In other words, a collection of glyphs with a particular style form a font face, a collection of font faces forms a font family, and a collection of font families forms the set of fonts available on a system.
Character encoding is a conversion table that maps characters codes to glyph codes in a font. For example, ASCII (American Standard Code for Information Interchange) is a common coding scheme found in most computers. The character encoding used in the Java(trademark) virtual machine is Unicode. For more information on Unicode, one may refer to http://www.unicode.org. It is expected that most virtual machines in the future will employ the Unicode encoding standard as it is designed to be a universal standard.
One of the most touted features of Java is its portability. With the xe2x80x9cwrite once, run anywherexe2x80x9d concept, it is envisioned that a Java application or applet could run on a mainframe computer and, without modification, also run on a hand-held device or Personal Digital Assistant (PDA). Obviously, a PDA and a mainframe computer have widely varying computing resources. So, a Java virtual machine (JVM) running on these platforms may have widely varying amounts of memory or bandwidth at its disposal, and a properly designed JVM should be designed to take advantage of the available resources while accomplishing the goal of portability. Hence, one of the implicit features of a JVM is its scalability-a JVM presents itself to a JDK application in a standard environment, which is valid across varying computer platforms. A properly designed JDK application should be designed to handle all of the combinations of computing resources which may be available on a host platform so that the application executes properly, i.e., a JDK application should be scaleable and variable.
Some users are more familiar than others with the scalability and variability of computer resources. Printer capability is one consideration of computer resources with which most users are familiar. Many users understand that printers can be fast or slow and that this speed varies for several reasons, most notably time versus complexity. For example, complex graphics may require more time to print. Many applications have printer driver settings, which allow a user to vary the quality of the printout from draft quality to high quality, and a user may choose a particular quality because of a previous, personal decision as to the requirements to be accomplished and the amount of time available to accomplish those requirements. However, the specified choice then becomes a value, which the application must use. For example, if the user chooses draft quality, then the application must produce draft quality. The application does not have the ability to provide a range of quality variability depending on the availability or scalability of particular computing resourcesxe2x80x94the user has already predetermined the outcome of the output. Heretofore, the scalability of the computing resources has not been presented to the user so that the user may have a minimal ability to specify a preference in the manner of using those resources across all applications. The user is not able to indicate a mere preference without mandating the outcome, for example, in a manner such as, xe2x80x9cQuality is not important, so if the computing resources for medium quality are not plentifully available, whatever those computing resources may be, then use available computing resources to generate adequate quality output.xe2x80x9d
As noted above, users are most notably aware of the tradeoffs involved in print processing. By noting that the tradeoffs involved in the preparation of any type of data for displaying are similar to those involved in printing, one may expand the recognition of the problem to generic data-presentation.
As Unicode is used in more applications, Java(trademark) applications will expect to be able to display and print both Latin1 and Latin5 Unicode glyphs simultaneously. Since portability is the most touted feature of Java(trademark), all Java(trademark) applications should attempt to be portable to a variety of locales. In order for such applications to remain portable, a generic scheme is needed for providing a range of quality variability while also handling Unicode glyphs.
This invention provides a user with the ability to specify variability in the generation of data for data-presentation on an output device, and these variability specification may be applied on a glyph-by-glyph basis to the presentation of glyphs. A data processing system provides processing of glyph-based quality variability requests in the following manner. The system receives a request for data-presentation of a series of glyphs and determines, for each glyph in the series of glyphs, whether quality variability is applicable to each glyph. If quality variability is applicable to each glyph, then the system determines a quality variance to be applied to each glyph based on predetermined data-presentation variability data and performs data-presentation of each glyph on an output device in accordance with the quality variance.
By providing quality variability on a glyph-by-glyph basis, a relatively simple glyph, such as those used for Latin1 characters, may be presented using low quality. However, a more complex glyph which may require a clear presentation of its more delicate detail for a proper comprehension of the glyph, such as various Chinese characters, are presented using high quality. In this manner, computing resources may be preserved or tailored on a glyph-by-glyph basis.